Efficient selection of memory resources through use of a graphics application programming interface (API) often proves elusive in practice. Classically, this selection is addressed by use of “bindings” (e.g., texture or vertex array bindings), where an application provides one or more central processing unit pointers or names of resources. A driver then looks up one or more objects and retrieves data required to program appropriate hardware, which usually requires sending graphics processing unit commands or populating a table in memory with that data. This is generally done one “access type” at a time, where an access type may be a texture, an unordered access view (UAV) or a vertex array, for example. Problems with this approach include providing a major source of central processing unit bottlenecks in most applications and in a reusing of display lists or precompiled command buffers, since some subset of resources usually needs to change from frame to frame.
Other, more recent application programming interface designs have approached this differently with moderate success. In a use of descriptor objects, binding information is placed in descriptors that are used to represent the memory resources, which may be efficient if the descriptors are completely static in nature. However, this approach involves some very high operational costs when modification of these descriptors is required, or an application is forced to wait for all previous uses of the descriptors to complete before modifying them and updates require expensive memory mapping operations. Additionally, these application programming interfaces do not have a notion of access types, so all access types are bundled together.
Another approach exposes “heaps” of descriptors, somewhat organized by access type, and binding resources that select a range of a heap (called a “table”). These descriptor heaps are large and required to reside in a same memory where descriptors are stored, and an application has an additional operating cost or burden of providing copies of these large descriptors. For example, a descriptor for a texture may require 32 bytes consisting of a texture's graphics processing unit (GPU) address, dimensions, format and several other properties. A requirement of only binding a range of a heap also necessitates significant redundancy in writing descriptors in that a descriptor may need to be shared in multiple tables. This application programming interface also organizes functionality into several “tiers” or feature levels, where applications are required to use very different coding patterns to take advantage of each tier. What is needed in the art is an improved way to manage the application of graphics resources.